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BACKGROUND OF THE INVENTION 

5 

Field of the Invention 

The present invention relates to CD-ROMs, more 
specifically to methods and apparatus for ordering 
10 individual music titles and recording them on a recordable 
audio CD. 

Description of the prior Art 

15 In the music industry, the basic method for selling a 

new album is to record a number of songs on a music support 
and then to distribute the song collection through sale 
terminals, such as music stores. This has been know for many 
years and, as technology advanced, music recording media 

20 have changed, from the old vinyl records, through magnetic 
cassettes to audio CDs, 

However, this common method of marketing music has 
various drawbacks. One of the most important is that people 
are obliged to buy a collection of songs even if they are 

25 only interested in a limited number of songs from that 
album. This fact may even lead people to illegally copy 
music from pre-recorded audio cassettes or CDs for making 
their own personalized collection of songs, available on the 
same recording medium. This results in great losses of sales 

30 for the music industry. 

A new method of commercializing music is suggested in 
US patent 3,990,710 to Hughes. A public kiosk is used for 
recording individual music titles as chosen by the client. 
Various songs from various singers may be recorded onto the 
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same music magnetic cassette thus providing to the client a 
personalized music album. However, recording on magnetic 
tape cassettes is not quite efficient since they deteriorate 
with time and with the number of plays. 

5 A similar type of public kiosk is disclosed in US 

patents 5,633,839 to Alexander et al. and 5,418,713 to 
Allen. In these patents, there is disclosed computer-based 
public kiosks that records digital music and data chosen by 
the client onto recordable CDs. However, the features 

10 provided by these inventions are not reliable enough, 
especially for the CD-ROM data writing. When a CD-ROM 
burner performs digital data writing onto an empty CD, data 
must arrive in continuous and constant data flow to the CD- 
ROM device in order not to leave blank spaces onto the CD- 

15 ROM, since those blank spaces, even having a relatively 
small size, may result in sound glitches when the CD-ROM is 
later listen by the client. The CD-ROM burner systems 
disclosed in these prior art patents do not provide accurate 
techniques for writing onto a CD-ROM. 

20 

Summary of the Invention 

It is therefore an object of the present invention to 
provide a reliable method and apparatus that allow clients 
to make their own musical selection and to record these 
songs on a CD-ROM support. 

It is also an object of the present invention to 
provide a public kiosk comprising electronic interface means 
for allowing a client to perform his/her musical selection, 
communication means for receiving from a remote server 
musical digital data, digital storing means for storing 
locally a large number of songs, optical engraving means, 
such as a CD-ROM burner for saving the selected music onto a 
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CD-ROM and payment means for billing the client for the 
musical selection . 

In another preferred embodiment of the present 
invention, the digital data arrives in a constant and 
5 permanent flow to the CD-ROM burner in order not to leave 
blank spaces onto the CD when recording, thus greatly 
improving the accuracy of the recorded music. 

In another preferred embodiment of the present 
invention, a large number of songs are stored locally, on a 

10 local hard disk drive inside the public kiosk for example, 
while other songs may be obtained via a high speed network 
such as a satellite link or via optical fiber, from one or 
more remote servers that contain larger selection of music. 
It is also an object of the present invention to 

15 provide the public kiosk with an user-friendly interface 
that allows the client to easily choose songs from a list of 
songs, wherein songs may be classified in many different 
ways, such as by musical style, year of issue, name of the 
singer, album title or other. The electronic interface is 

20 easy-to-use even for a computer non-initiate person and may 
comprise a tactile screen, or a keyboard in association with 
a screen. 

Another object of the present invention is to provide 
electronic modules that performs advising for the client 
25 concerning the music to be recorded onto the CD-ROM support. 
This advises may be based on previous selections of this 
client, by association with another singer or songs, or may 
be based on personal information of the client (age, sex, 
etc) . 

30 
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Brief Description of the Drawings 

The scope of the present invention will be better 
understood with reference to the following drawings: 

Figure 1 shows a high level block diagram of the 
overall system used with the present inventions- 
Figure 2 shows a general hardware block diagram of a 
preferred embodiment of the present invention; 

Figure 3 shows a detailed block diagram representing 
the data passage from a hard-disk drive to the CD-ROM 
burner; 

Figure 4 shows a preferred embodiment of the present 
invention, namely the fuel gauge; 
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Detailed Description of the Preferred Embodiments 

While the ideas contained herein are applicable to any 
type of digital data (e.g. text, computer software, audio, 
5 video etc.), the present invention will be described with 
reference to the delivery of digital audio data from a 
remote repository, through a high-speed link, to an end- 
point. 

Further, while the consumer can select either entire 
10 audio recordings of an album (e.g. an entire CD-ROM 
available on the market) or a la carte tracks (user 
selections), this document will limit its discussion scope 
to the audio tracks (e.g. songs from a Compact Disc). 
Entire recordings are nothing more than a preset selection 
15 of tracks. 

At the highest level, the present invention comprises a 
local public kiosk also called the end-point in the present 
application, a high speed communication link and a number of 
repositories which are remote servers containing large 
20 selection of music. 

The repository is simply the place where the digital 
data (i.e. audio tracks) is stored on local storage means, 
such as a hard drives. It should be noted that even if other 
storage means may be used as well, both for the local kiosks 

25 and for the repositories, the present application will refer 
to a hard drive as being the storage means. The repository 
may be situated in one or more locations. These multiple 
repository locations are themselves connected via a 
communications infrastructure so they appear to the end- 

30 points to be a single entity. 

Joining the repository to the end-points is a 
communications infrastructure. It is suitable that this 
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communications infrastructure will consist of a high-speed 
connection because of the potentially large volumes of data 
that may have to be moved from the repository to the end- 
point. 

5 Figure 1 illustrates the general block diagram of the 

present invention. 

The end-points will be packaged differently depending 
on their location. One set of end-points may be deployed in 
a public access setting, while others may be used in the 
10 home (in the form of consumer electronic devices). 
Moreover, on one hand, there is a need for a more robust 
industrial grade enclosure, on the other, esthetics and cost 
may be more important. 

Regardless of physical packaging, the end-points all 
15 comprise an user manager that performs the user interface 
program, a file manager for managing the song selections and 
of a communication manager for downloading the song 
selections that are not available locally and for validating 
credit card payments. 

20 Each of these managers is a software application that 

executes using specialized hardware, in accordance with its 
predominant task. Further, each of these managers may be 
tightly coupled (i.e. on a single computer with each manager 
being a task within a real-time, multitasking operating 

25 system) or loosely coupled (i.e. on multiple computers 
connected through communication channels). 

While each manager has been named in accordance with 
its predominant function, each of the managers may contain 
within it, other functions. For example, each manager may 
30 have a message delivery and queuing function, a timer 
function, a communications function, an I/O function etc. 
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Periodically there will be a requirement to process 
additions/deletions and changes. The List Synchronizer will 
communicate with the File Manager to obtain the latest list 
of content. Since the File Manager manages the tracks, only 
5 the list of available tracks (not the tracks themselves) has 
to be given to the Repertoire List Synchronizer. 

Each public kiosk may be composed of one or more 
computer systems. It appears that it is preferable to have a 
plurality of computers, since it is better for each one to 

10 run a single application than to have a more powerful multi- 
tasking computer running a few applications. Therefore, this 
distributed architecture was created to provide maximum 
flexibility. It can, for example, take advantage of the 
fact that three commodity computers each executing a manager 

15 could potentially be more cost effective than having a 
single more powerful machine executing all three managers 
under a multi-tasking operating system. Such an architecture 
is shown in Figure 1, wherein the user manager runs onto a 
Windows 97 system while the CD burner runs of a DOS machine. 

20 Another advantage of this architecture is that it 

allows one or more User Manager (s) to operate with zero or 
more File Managers, to operate with one or more 
Communication Manager(s). The significance of this can be 
better illustrated through an example. Let's assume for a 

25 moment that each manager is running on a separate computer. 
If it is determined that the user interacting with the User 
Manager is the rate-limiting step in the process (i.e. the 
User Manager's execution time is some multiple of the time 
required by the File Manager), cost reductions can be 

30 realized by having multiple User Managers operating in 
conjunction with a single File Manager. 



7 



CA 02225190 1997-12-18 



The minimum functioning architecture for the public 
kiosk consists of a single User Manager and a single 
Communication manager. This would be analogous to a 
personal jukebox located in the home where selections are 
5 purchased from the available repertoire, downloaded and 
stored internally on a storage means . 

At the other extreme, end-points deployed in a public 
access setting (such as a retail outlet) may be grouped in 
10 clusters. Each cluster may consist of one or more User 
Managers, zero or more File Managers, and one or more 
Communications Managers. 

In a preferred embodiment of the present invention, a 
cost effective architecture is used and implies to have the 
15 User Manager on one computer and the File and Communications 
Managers on a second - with a communications link between 
the two computers. 

The User Manager's primary responsibility is to 
solicit, and guide a user through the process of making 
20 audio track selections. Once the choices are made, they are 
confirmed, the payment method chosen and the credit 
verified. The process then proceeds to the manufacturing 
phase, which is in the domain of the File Manager. 

When the end-point is not involved in interacting with 
25 a potential customer, (i.e. the end-point is idle,) control 
is turned over to the Advertising Manager. Once potential 
customers identify themselves to the end-point, the 
Advertising manager turns control back over to the Coach - 
The coach is an extremely user friendly piece of software 
30 that helps customers through the selection process. 

Besides being able to browse selected lists of tracks 
(e.g. local specials, top 100, latest releases etc), the 

8 
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potential customer is also offered the ability to search for 
audio tracks. The search may be performed by looking for an 
artist, a particular sound track, a label, an year of issue, 
a genre (e.g. Blues, Jazz etc) or an subtext within lyrics. 
5 The search facility is easy to use, and the selection of 
tracks is retained across searches on a session by session 
basis. In the event that the customer cancels the selection 
process, he/she is offered the choice to save the tracks 
selected so far in anticipation that the selection process 
10 will continue later. 

In another preferred embodiment of the present invention, 
the digital data arrives in a constant and permanent flow to 
the CD-ROM burner in order not to leave blank spaces onto 
the CD-ROM when recording, thus greatly improving the 

15 accuracy of the recorded music. This architecture is shown 
in Fig. 2 wherein data is first stored onto a hard disk 
drive in an compressed and encrypted format. When a song 
track is requested by the user, the digital song is 
decompressed and decrypted by the Decompression and 

20 Decryption Module, the stereo bit frame is created by the 
Framing Module and data get into the CD-ROM buffer in a 
continuous and steady flow. This buffer must never be empty 
in order to be able to feed the CD-ROM burner constantly 
with data so it may constantly burn the CD-ROM disk. The 

25 reason for this is that when a CD-ROM burner does not have 
any more data in its buffer to engrave on the disk, it does 
not stop immediately engraving but rather put a number of 
zeros (0) on the disk after finishing engraving the valuable 
data. These zeros are then left on the disk because at the 

30 next CD-ROM head passage, data will be engraved on the disk 
at the end of the zeros stream. This string of zeros is then 
audible at the playback time, thus reducing the recording 
accuracy of the disk. This is the reason because the sound 
tracks are stored on a hard disk drive instead that on a CD- 
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ROM drive: the hard-disk allow a steady stream of data to be 
read from it so it provides continuous flow of data toward 
the CD-ROM burner, while a CD-ROM reader would sequentially 
read data, output data and replace its head reader, thus not 
5 providing continuous data flow* This embodiment of the 
present invention is showed in Figure 2. 

An Internet Web (WWW) Site may also be made available 
to potential customers to allow off-line choosing. This web 
site will allow potential customers to browse and search the 
10 repertoire, listen to sound bites from tracks and save their 
selections. When the customers then visit the end-point and 
identify themselves, their pre-chosen track list(s) will be 
recalled and the end-point can immediately proceed to the 
recording process (after customer confirmation). 

15 The Web Site may also e-mail notices and special 

promotions on an ongoing basis (provided that the customer 
has requested to be added to the mailing list). 

If at the end of the search process the customer has 
been unable to find the particular track that they were 

20 looking for, the system will prompt and request a few lines 
of text to help identify what they were looking for (e.g. 
artist/title guess/recording date etc). This information 
will then be sent to Customer Service and will be used to 
track the lost opportunity. This lost opportunity might 

25 also be communicated to the respective audio track owner(s) 
so that it can be added to the repository and made available 
to the customer. Over time these statistics will be very 
useful to record labels, as it will help them decide which 
titles from their catalogues should be made available. 

30 As mentioned above, regardless of the track selection 

process (searching, browsing etc), the tracks chosen are 
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retained and calculations are performed to indicate both the 
cost, and the accumulated time as shown in Figure 4. 

The repository may also have the flexibility to 
associate sophisticated business rules on a track by track 
5 basis. These business rules are applied in real-time as 
each track is selected to provide the customer with track 
costing. The track owner(s) may provide the business rules. 

There also may be a need to apply business rules based 
on certain collections of songs. For example, record labels 
10 may require that new releases be only delivered in their 
entirety (since the same collection of songs might be 
available through traditional retail channels). This will 
most likely be done to preserve the investment made in the 
production of the new release by the record label. 

15 These business rules (associated with collections and 

with each track) will take into consideration such things 
locale, currency exchange, taxation, tariffs, royalties and 
time-limited promotions. This kind of flexibility may be 
provided to protect the existing business models of the 

20 record labels. 

Once all the tracks have been chosen, the user may be 
asked to allow the File Manager to reorder the tracks. This 
will be done when it is discovered that the tracks that are 
local are interleaved with tracks that have to be 
25 downloaded. If the missing tracks can be retrieved while 
the other locally cached tracks are being produced, the 
amount of time that the consumer has to wait is reduced. 

The client terminal may also provide a music advisor 
service for customers wanting to be helped in their musical 
30 selection. Assume for a moment that a customer has chosen 
three or four tracks. Further, suppose that he/she is not 
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interested in continuing the selection process but wishes to 
be offered advice on other tracks that could be added to the 
list. The Music Advisor feature of the User Manager will 
offer suggestions of other tracks that the customer may be 
interested. These additional tracks will be suggested using 
essentially two mechanisms: 

1) Based on categorizing songs and/or artists 
together (e.g. if you like Ella Fitzgerald, you 
might also like Billie Holiday). This 
categorization is already being done by critics, 
fan clubs etc. The system will offer multiple 
categorization facilities so that the Music 
Advisor can offer additional selections based on 
reviews, genre, top 10 statistics and other sorts 
of groupings. 

2) The second method for suggestions will be based on 
tracking the history of previous selections. From 
day one, the Music Advisor will track the song 
lists that other customers have chosen and infer 
that certain songs seem to have an affinity for 
one another. A grouping of songs based on an 
affinity is referred to as clustering. To offer 
additional suggestions for tracks, the Music 
Advisor simply examines the customer's current 
choices, locates those songs 1 cluster(s), and 
offers the other members of the cluster as 
suggestions . 

The songs suggested by the Music Advisor will improve 
over time as historical selections accumulate and 
alternative suggestion "advice" is made available from 
critics, clubs and other sources. 
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The Music Advisor may also be made available through 
the Off-line Choosing facility previously mentioned. This 
will allow people to spend as much time as they like (in the 
comfort of their homes), to create the right combination of 
5 musical selections. Upon completing their list, they save 
it and that list is later retrieved when they arrive at the 
end-point. 

The Advertising Manager will ensure that any self- 
promotion or advertising done on behalf of a third party is 

10 up to date and tracked. This will ensure that the promotion 
gets the frequency of exposure agreed to. It might also be 
desirable to air certain advertisements during particular 
days or even at particular times during the day. The 
Advertising Manager will create an audit trail showing 

15 exactly when the promotional information aired. The 
Advertising Manager also ensures that the advertising 
content is up-to-date by synchronizing with the repository. 

To foster repeat sales, a loyalty system will be 
established that will remember tracks selected via an 

20 Internet Web site and a frequent buyer program implemented. 
The intention is to have an electronic cash token with a 
unique ID that identifies the customer to the system so that 
it can recognize and cater to the individual's needs and 
tastes. The Loyalty Manager (client side) will communicate 

25 with the Loyalty Manager (Server Side) to retrieve and 
update the customer info. 

The Unified Payment Manager presents a common dialog 

and interface to the application regardless of the method of 

payment. The most suitable payment method is using credit 

30 cards but other payment methods may be used as well, such as 
cash or debit card. 
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Since our potential customers may not be of the age of 
majority, the system will accommodate the use of an 
electronic-cash (e-cash) token. The e-cash token can be 
given as a gift preloaded with a selection of songs, song 

5 credits or simply with soft currency (i.e. e-cash proper). 
It might also be desirable to have the record labels 1 and 
maybe the artists' offer their own loyalty tokens. The 
packaging of the loyalty tokens may be in the form of debit 
cards or other in other shapes and sizes such as pendants or 

10 wristwatches . 

Periodically there will be a requirement to process 
additions/deletions and changes. The List Synchronizer will 
communicate with the File Manager to obtain the latest list 
of content. Since the File Manager manages the tracks, only 
15 the list of available tracks (not the tracks themselves) has 
to be given to the Repertoire List Synchronizer. 

As each track is chosen (using any of previously 
described methods) the User Manager sends the track title to 
the File Manager so that it can: 
20 1) Retrieve the cost of the track title based on the 

recorded business rules (i.e. royalty, exchange 

rate, and markup). This will be done via the 

Unified Payment Manager (Client Side). 

2) Verify that the chosen track title is being cached 
25 locally - and if not - then 

3 ) The Communications Manager will consider 
downloading the track title from the repository 

It is imperative - particularly during the production 
process - that determinism be foremost in the implementation 
30 of the File Manager and the Communications Manager. An 
embedded application or a real-time operating system will be 

14 
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used to ensure that performance objectives are met and that 
production of the recording and communications occur on 
tight deadlines. 

In addition to being given notice of a user's desire to 
5 purchase a particular track, a Predictive Downloader will 
also consult other end-points (most likely on a regional 
basis) to anticipate the list of tracks that need to be 
cached locally. This will most likely occur in the off- 
hours . 

As tracks are added at the repository, a repertoire 
synchronize command is sent to each end-point (in a 
staggered fashion, to avoid a broadcast storm). The 
repertoire synchronizer then requests the 

adds/changes/deletions from the repository and updates its 
database of tracks to reflect the changes. 

The adds/changes/deletions are then sent to the User 
Manager (Repertoire List Synchronizer) so that the latest 
and most complete list of tracks is always available to the 
consumer. 

As part of the recording process, the peaks and valleys 
(minimum and maximum) will be determined and stored with the 
track information. When it comes time to produce a recording 
of a number of tracks, the minimum and maximum will be 
considered against other minimum and maximum for the other 
25 tracks and a compensation value will be calculated for each 
track. This is necessary because each track has the 
potential of being recorded at different volume levels 
producing a very noticeable increase/decrease in volume from 
track to track. This Recording Level Normalization is done 
30 to prevent the consumer from having to continually adjust 
the volume at playback time. If however an entire recording 
is chosen, no Recording Level Normalization will occur. 

15 
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This will ensure that a copy of this recording from a retail 
store will sound identical as compared to the copy produced 
by the end-point. 

The Communications Manager will be implemented 
5 independently of the physical network. The only assumption 
will be that the network protocol will be IP. This will 
allow for the adoption of the best and most cost effective 
communications mechanism. Currently IP is supported over 
more communications networks than any other protocol. 
10 Examples of physical networks that may be used with the 
present invention are: Satellite, ISDN, ASDL, ATM, Ethernet, 
Token Ring and voice grade modems over POTS (plain old 
telephone system). 

All communication traffic that is of a sensitive nature 
15 that cannot be conducted across a secure channel (where both 
ends of the communication pipe are controlled) will be 
encrypted. Encrypted traffic will occur particularly if a 
public network has to be traversed such as the Internet. 
Security will be of the utmost importance for credit card 
20 transactions and anywhere privacy is paramount. 

The Music Advisor Module is located at the server side 
(the repository) and will accumulate user choices in an 
effort to identify patterns where songs have been chosen and 
manufactured together. This is referred to as clustering. 
25 Collections of songs will be sent from the end-points and 
stored at the repository under the control of the Music 
Advisor (Server Side) where clusters will be identified and 
will then be provided to the end-points to help users in 
selecting tracks. 

30 The Music Advisor (Server Side) will also be the keeper 

of the pre-selected collections from Critics, Artists and 

16 
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Fan Clubs. An unlimited number of collections of this sort 
can be made available. 

Self-promotion and paid-for advertising will be created 
at the repository, put under the control of the Advertising 
5 Manager (Server side) and subsequently pushed to specific 
end-points (where it will be managed by the Advertising 
Manager (Client Side) ) - 

The frequency and exposure of the advertisement will be 
tracked by the individual end-points and those statistics 
10 will be passed back to the Advertising Manager (Server Side) 
to provide an audit trail to advertiser that their content 
has indeed aired. 

The Loyalty Manager (Server Side) will track on a 
system wide basis individuals who are planning to use or who 
15 are already using the delivery system. Purchase history as 
well as specific interests and choices will be tracked in an 
effort to make the system friendly and accommodating. 

Track lists chosen through the Web site or at the end- 
points may be stored here and delivered to the end-points on 
20 an as needed basis. These lists must be tracked at the 
repository to make them available. Statistics may also be 
made available (under privacy rules) to those who need to 
know the activities of individuals. 

The repertoire for a given region may be different than 
25 another. For example, the music that is cached locally in 
Spanish regions may most likely be different than the music 
that is available in English speaking regions. Further, 
particular genres may be more predominant in certain areas 
(e.g. Country versus Rock). 
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The Repertoire Evolver may gather statistics of tracks 
cached by the end-points and accumulate regional statistics. 
These lists may then be made available to other end-points 
in the region in an effort to anticipate the customer's 
5 choices. 

A Unified Payment Manager located at the server side 
will act as an intermediary between end-point credit 
verification and the respective credit granters. The Unified 
Payment Manager (Server Side) may cache a list of bad credit 

10 cards to prevent unnecessary communication with the credit 
granter's system. By having all credit transactional 
information flowing through the Unified Payment Manager 
(Server Side), adding additional creditors and ensuring 
timely and up-to-date information regarding the purchaser 

15 will be greatly simplified. 

The Unified Payment Manager (Server Side) will also 
factor in business rules and will be sensitive to exchange 
rates, taxes and other costs of doing business. 



20 Hardware requirements 

The User Manager provided with a public access terminal 
may use COTS (common off the shelf) parts. A touch 
sensitive screen with appropriate user interface may be also 
provided to simplify and make more rugged the end-point. 

25 The only specific hardware requirement is the need for 

a communications mechanism to the File Manager (and the 
Communications Manager). Currently this has been achieved 
using an RS-232C connection. However, if the number of User 
Managers (on the front-end) out-number the back-end units, a 

30 multi-drop or network approach will have to be deployed. 
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Since the entire user interaction occurs with the User 
Manager, it is important to make it operate as independently 
as possible from both the File and Communications Managers. 
This will be particularly important if the user decided to 
5 engage in some compute intensive activity such as playing a 
full motion video. The File and Communications Managers 
must have a deterministic response if success is to be 
achieved in the production of the recording. 

The File Manager requires access to potentially a large 
10 amount of disk space. As such, hardware with a SCSI bus may 
be employed to ensure a large storage space and achieve the 
performance requirements . 

The hardware requirements have to satisfy the needs of 
potentially multiple writing devices. Calculations and 
15 testing have proven that this activity, while not compute 
intensive, is I/O intensive. 

The repository will be a large-scale disk farm. Since 
the repository is vital for the success of the operation, 
the repository will be constructed to be highly scaleable, 
20 and have high availability. Further, it will be distributed 
(not centralized). 

From the end-point perspective, the repository will 
appear to be a single entity but for the purposes of not 
having a single point of failure, the repository will be 
25 divided between two or more geographical locations. This 
will decrease the possibility of a catastrophic event (e.g. 
earthquake, flood etc) shutting down the operation. 

The repository will also operate on 7x24 (seven days a 
week, 24 hours a day). Each of the repositories will have a 
30 near complete copy of all the digital data that is available 
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for delivery. Synchronization mechanisms will be employed 
to ensure that all repositories are up-to-date. 

A Customer Service facility will also be established at 
one or more locations (perhaps housed in the same physical 
5 location as one or more of the repositories). Customer 
Service will respond to customer inquiries and provide a 
mechanism to ensure customer satisfaction. 

The inter-manager communications will be based on 
message passing. This message passing mechanism will be 
10 implemented independent of the underlying transport protocol 
or physical layer. 

The inter-manager communication may be an efficient 
module. It may not tax the processor when tasks are local 
to the same memory space, but it will be robust enough to 
15 support the guaranteed delivery of messages. It may also 
include a time-out facility to prevent deadlocks (because of 
a message getting lost). 

The repository to end-point communication will be via a 
high-speed satellite connection using a broadcast model. 
20 With exceptionally high speed pipes and the ability to 
update multiple end-points simultaneously, this is an ideal 
communication mechanism for digital data delivery. 

Since very small quantities of data flow from the end- 
point to the repository (e.g. credit card authorization 
25 requests, purchase information, advertising frequency and 
time of day, etc.), a much slower communication channel can 
be used. As such, it is anticipated that the end-point to 
repository communication will be via a 56K modem over POTS. 

Since the end-points in retail location will 
30 essentially be idle at certain times in the day, it will be 
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possible to have them perform their maintenance chores (e.g. 
updating local cache of songs, performing system checks and 
diagnostics, etc) in off hours. This will allow for lower 
cost operation since most telephone companies offer 
5 discounts from 18:00 till 06:00 the next day. 

Hardware Equipment 

To better understand some of the details surrounding 
10 the movement of data in the writing of digital audio data, 
consider the following tables which provide examples of the 
hardware equipment needed in order to implement a system as 
the one disclosed by the present invention. It has to be 
noted that these hardware equipment are only provided as an 
15 example and are not restrictive under any circumstances. 
Other combinations of materials may be used as well. 



Most Common PC Bus Architecture Characteristics 





ISA 


EISA 


Micro Channel 


VL-Bus 


PCI 


Data Path Width 


8/16 


32.00 


16/32/64 


32/64 


32/64 


Data Bus Speed (MHz) 


5.33/8.33 


8.33 


10.00 


33/50 


33.00 


Data Transfer Rates (MB/sec) 


5.33/8.33 


33.00 


20/40/80/160 


132/264 


132/264 


Data Rates Implemented (MB/sec) 


5.33/8.33 


33.00 


40 (PS/2)/80 (RS/6000) 


132.00 


132.00 


Number of Slots 


0-8 


[)-8 


0-8 


0-2 


0-4 


Bus Masters Supported 


No 


Yes 


Yes 


Yes 


Yes 


Data/Address Parity 


No 


No 


Yes 


No 


Yes 


Sync, Channel Checks 


No 


No 


Yes 


No 


Yes 


Card ID/Auto Configuration 


No 


Yes 


Yes 


Yes 


Yes 


Works with MC/ISA/EISA 


N/A 


N/A 


N/A 


Yes 


Yes 
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Theoretical Throughput of Typic al Device Buses 





SCSI2 


Fast Wide SCSI 


Data Transfer Rate (MB/sec) 


10 


20 



Performance R equirements for Various Speeds of CR-R Writers 





lx Writer 


2x Writer 


4x Writer 


8x Writer 


16x Writer 


45 min CD 

(mm:ss) 


45:00 


22:30 


11:15 


5:37 


2:48 


Or (MB/sec) 


0.15 


0.29 


0.59 


1.17 


2.34 



5 Most device buses (e.g. SCSI) are relatively low speed 

as compared to the internal buses currently being used in PC 
architecture (e.g. PCI). Therefore it can be seen that the 
data transfer rate across the device bus will in no way tax 
the internal bus. And the throughput required in writing to 

10 the CD-R device(s), would not tax the SCSI bus unless 
multiple high-speed writers are simultaneously employed. 

Given that the current architecture uses SCSI as the 
device bus and PCI as the internal bus, it can be seen that 
a single SCSI bus could easily support 32 writers (even 
15 though the SCSI bus specification only supports 8 addresses 
(one for the controller and 7 devices)). Separate buses also 
allow better caching at the operating system level improving 
application performance. 

It should also be noted that the data being read from a 
20 CD-ROM and ultimately being written to CD-R must traverse 
two buses, three times: upon reading, the data travels 
across the device bus then across the internal bus. Upon 
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writing, the data travels across the internal bus then 
across the device bus. The writing step is repeated. 

Since the device bus is the limiting factor in moving 
the data, attention has to be paid to make sure that these 
device buses are optimized. So for example, in an effort to 
provide consistency between the reading and the writing 
operations (particularly if there is more than one writing 
device), two SCSI buses may have to be used. The first bus 
will support the drives storing the track data, the second 
bus would support the CD-R writer(s). 

In a preferred embodiment of the present invention, 
SCSI CD-R drives from Kodak (PCD600) and Yamaha (CD400) are 
used as CD-ROM writers since they are capable of 
consistently produce error free recordings. In the case 
where multiple disks are daisy-chained together, a fast, 
wide SCSI bus may be employed to ensure that data is 
delivered to the CD-R Writer before its buffer is starved. 
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